The Session Initiation Protocol (SIP) is a protocol for creating, modifying, and terminating computer network-based communication sessions, such as for an Internet-based telephone call between two or more participants. Since its introduction numerous enhancements to SIP have been proposed, including a SIP event notification framework in which SIP is used to send notifications to a subscriber regarding changes in a resource's state information as detected by a presence server when new state information for the resource is published. Further enhancements, such as those described in RFCs 4660 and 4661 of the Internet Engineering Task Force, provide a mechanism for filtering such notifications through the use of filtering rules optionally having one or more “trigger” elements that specify what resource state changes must occur before a notification is sent, and optionally having one or more “what” elements that specify the content of a notification. For example, a trigger may specify that a notification be sent when a resource's “sphere” (role) attribute has changed to “work”, while a “what” may specify that only the portion of the resource's state information related to the resource's available communication means be included in the notification. Where a filter has a trigger without a “what”, if the trigger condition is met, all of the resource's presence information is sent in the notification. Where a filter has a “what” without a trigger, the specified presence information notification is sent following any change in the resource's state information. Each trigger element includes one or more “changed,” “added,” and “removed” elements describing specific types of state change conditions that are to be evaluated by the presence server when new state information for a resource is published, where the presence server compares the new state information with the resource's previous state information.
When new resource state information is published, the presence server must evaluate all of the filtering rules of all of the subscriptions to a resource. As resource state information is typically embodied in an XML document, triggers typically employ XPath expressions to indicate the location of state information within the XML document that is to be evaluated. Thus, to evaluate the triggers in all the filtering rules, the presence server must evaluate all their XPath expressions in both the newly-published XML document, as well as the previous XML document, as each “changed,” “added,” and “removed” element requires that its associated XPath expression be evaluated for both documents in order to allow a comparison to be made between the documents. Unfortunately, as the numbers of subscribers, filters, triggers, and XPath statements grow, the presence server requires more and more processing power in order to perform these XPath evaluations.
One approach to evaluating such filters involves processing the subscriptions one at a time, where for each subscription that has filtering rules, and for each trigger of a filtering rule, the presence server evaluates the trigger for the resource's new and previous XML state information documents. If the trigger condition is satisfied, the presence server applies the filter's “what” elements to the new document and sends out a notification with the “what”-specified information to the subscriber. The evaluation of triggers in this approach may be performed using the Document Object Model (DOM), where both the previous and new XML documents are parsed using a DOM parser to create separate DOM trees upon which each XPath expression is evaluated. This approach can be optimized by reusing the DOM trees of the previous and new XML documents for all XPath evaluations of all subscription for the same resource. This approach may be further optimized by caching the results of XPath searches such that if a particular XPath expression is repeated in more than one filter, it need only be evaluated once. However, even with these optimizations, performing XPath searches on DOM trees is processing-intensive.
Another variation of the above sequential processing approach involves using a streaming parser to evaluate XPath expressions, such as a parser that uses the Simple API for XML (SAX). The SAX model is believed to be more efficient than the DOM model in terms of memory usage and processing requirements for evaluating XPath expressions. However, in order to evaluate the SIP filters described above, current techniques call for the streaming XPath evaluation to be repeated for each XPath expression across all filters, giving sequential evaluation with the SAX model little or no advantage over that of the DOM-model.